Date: Tue, 12 Dec 2006 09:09:24 +0900 From: Jun Kuriyama <kuriyama@imgsrc.co.jp> To: Doug Barton <dougb@FreeBSD.org> Cc: ports@FreeBSD.org Subject: Re: HEADS UP : security/gnupg will be upgraded to 2.0.1 Message-ID: <7mr6v6ht57.wl%kuriyama@imgsrc.co.jp> In-Reply-To: <457DA05F.8010805@FreeBSD.org> References: <7mu003jdyg.wl%kuriyama@imgsrc.co.jp> <457DA05F.8010805@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
At Mon, 11 Dec 2006 10:15:59 -0800, Doug Barton wrote: > Thanks for letting us know what you're plans are. I think you know > what I'm going to say next. ;) As I suggested when I wrote to you in > private e-mail some time ago, I think it would be more in line with > the plans that the developers have for GnuPG 2.x to keep the existing > gnupg port dedicated to the 1.x branch, and repo copy gnupg-devel to > gnupg2. Quoting from the README for 2.x: > > GnuPG 2.0 is the stable version of GnuPG integrating support for > OpenPGP and S/MIME. It does not conflict with an installed 1.4 > OpenPGP-only version. > > Note that there is no binary gpg but a gpg2 so > that this package won't conflict with a GnuPG 1.4 installation. gpg2 > behaves just like gpg. > > GNUPG 1.4 AND GNUPG 2.0 > ======================= > GnuPG 2.0 is a newer version of GnuPG with additional support for > S/MIME. It has a different design philosophy that splits > functionality up into several modules. Both versions may be installed > simultaneously without any conflict (gpg is called gpg2 in GnuPG 2). > In fact, the gpg version from GnuPG 1.4 is able to make use of the > gpg-agent as included in GnuPG 2 and allows for seamless passphrase > caching. The advantage of GnuPG 1.4 is its smaller size and no > dependency on other modules at run and build time. > </quote> > > Further, in discussion on the gnupg-users list the developers have > clearly stated that they will continue working on at least the 1.4.x > branch of GnuPG for the foreseeable future. > > Therefore I think it would be more in line with the development goals > for the GnuPG project, and less confusing for new users coming to > FreeBSD from other platforms, to adopt the naming scheme that I > proposed, although not necessarily the exact patches I sent you to > implement it. > > If you choose not to go that direction, I would be interested in > hearing your reasoning. At first, thank you for your helping to upgrade our gnupg world to 2.0.x. And sorry I cannot explain as you can feel reasonable. I just think "security/gnupg" should be used as "what you should choose" for "GnuPG". If new ports user wants to install GnuPG, I hope there is "security/gnupg" as recommended stable version. I understand GnuPG developers think 1.4.x will be kept, but I think dependents will migrate to use modularized 2.0.x line. Though development is continue, Number of API consumer of 1.4.x line will be getting smaller. So, for 1 or 2 years later, I think existance of good stable "security/gnupg" and historical "security/gnupg1" will be less confusing (IMHO). GnuPG development will continue. So there will be GnuPG 3.x line. Above approach can be adopted. Anyway, this way maybe old-porters thinking. I liked to use "<category>/<portname>" directory name (without version number). Using version number in ports directory is very exceptional event for keeping old ports (like "emacs", "emacs19", "emacs20"). I thought this is the way to indicate "what you should choose" for port users. But, there are port directories with version number than past. I can change my mind if it is suitable recently. -- Jun Kuriyama <kuriyama@imgsrc.co.jp> // IMG SRC, Inc. <kuriyama@FreeBSD.org> // FreeBSD Project
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7mr6v6ht57.wl%kuriyama>